8354464: Additional cleanup setting up native.encoding #24607

stuart-marks · 2025-04-12T02:19:35Z

Remove the #ifdef MACOSX from platform-independent System.c, which (on Mac) sets native.encoding from sprops.encoding or (on non-Mac Unix and Windows) sets native.encoding from sprops.sun_jnu_encoding. After this removal, the native.encoding property will be set from sprops.encoding and the sun.jnu.encoding property will be set from sprops.sun_jnu_encoding.

Change the windows java_props_md.c so that it initializes sprops.sun_jnu_encoding and then copies that value to sprops.encoding. Previously, sprops.encoding was initialized with data from other Windows APIs, but this value was ignored by platform-independent code, which was kind of confusing.

There are no changes to the Unix (Mac & non-Mac) platform-specific code. It already has code to set sprops.encoding and sprops.sun_jnu_encoding properly, including macOS-specific code to set the latter to UTF-8 unconditionally.

There should be no behavior changes on any platform.

I changed variable names in windows/java_props_md.c to make it clear that the values stored into them are unused. Of course there are other possibilities here, such as changing the interface to SetupI18nProps(). I'm open to suggestions.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8354464: Additional cleanup setting up native.encoding (Enhancement - P4)

Reviewers

Naoto Sato (@naotoj - Reviewer)
Alan Bateman (@AlanBateman - Reviewer) Review applies to 37cd3ed2

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/24607/head:pull/24607
$ git checkout pull/24607

Update a local copy of the PR:
$ git checkout pull/24607
$ git pull https://git.openjdk.org/jdk.git pull/24607/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 24607

View PR using the GUI difftool:
$ git pr show -t 24607

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/24607.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-04-12T02:20:15Z

👋 Welcome back smarks! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-04-12T02:20:23Z

@stuart-marks This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8354464: Additional cleanup setting up native.encoding

Reviewed-by: naoto, alanb

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 56 new commits pushed to the master branch:

31e293b: 8354552: Open source a few Swing tests
3e3dff6: 8354451: Open source some more Swing popup menu tests
e163a76: 8354106: Clean up and open source KeyEvent related tests (Part 2)
... and 53 more: https://git.openjdk.org/jdk/compare/cec48ed270d3bdf704c389a091b42a32c2ed6440...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2025-04-12T02:20:50Z

@stuart-marks The following label will be automatically applied to this pull request:

core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2025-04-14T22:27:53Z

Webrevs

naotoj

Thanks for the clean-up, Stuart. Looks good to me.

naotoj · 2025-04-15T17:04:35Z

src/java.base/share/native/libjava/System.c

    PUTPROP(propArray, _native_encoding_NDX, sprops->encoding);
-#else
-    PUTPROP(propArray, _native_encoding_NDX, sprops->sun_jnu_encoding);
-#endif
    PUTPROP(propArray, _sun_jnu_encoding_NDX, sprops->sun_jnu_encoding);


Since we now got rid of platform depenence here, would it make sense to perform non-null assertion in Java level here? I remember in the last PR we added assert in platform C code.

Java level -> Platform independent C level
Sorry

Good idea. Done.

…ding

AlanBateman

I've gone through this, I don't see any issues.

RogerRiggs · 2025-04-16T14:43:45Z

src/java.base/windows/native/libjava/java_props_md.c

@@ -660,22 +660,19 @@ GetJavaProperties(JNIEnv* env)
                           &sprops.format_script,
                           &sprops.format_country,
                           &sprops.format_variant,
-                           &sprops.encoding);
+                           &format_encoding_unused);


A cleaner change would be to modify SetupI18nProps to remove the encoding argument.
SetupI18nProps is a file local static function, there are no other uses.
And drop the dummy variables.

The main focus of this commit is to straighten out the logic between the platform-specific and platform-independent layers.

In the previous state of this file, tracing the origin of the properties on Windows, I ended up following the origin of sprops.encoding all the way through SetupI18nProps, only to find that was ignored entirely at the platform-independent layer. So this change is an improvement in that it clarifies where sprops.encoding comes from, and that SetupI18nProps does some computations that end up being thrown away instead of being stored into a shared data structure that's eventually ignored.

Of course that path is dead code and could be removed without changing the behavior. But this code has a tortured history and it's not entirely clear that it's correct in its current state. In fact @naotoj considered making some changes in this logic JDK-8352917 but decided against it. However it seems like a possibility that we might revisit this?

Also note that we're now talking about how Windows gets its encoding information from the OS, and not how encoding information is transmitted up through the layers into Java properties, which is the focus of this cleanup.

Anyway I'd like to hear from @naotoj on this. If we're certain the extra stuff in SetupI18nProps is useless, we should clean it up now. But if there might be a use for this information -- maybe stdin.encoding? -- then perhaps it's better to leave it as is.

I belive they can be removed as they are no where used (and I don't think it will be used for stdin.encoding either) So I prefer removing those unused code now.

OK, I've done so. Now testing on Windows....

(CI run built and passed all tests, including on Windows.)

naotoj

LGTM!

stuart-marks · 2025-04-17T18:30:26Z

/integrate

openjdk · 2025-04-17T18:31:11Z

Going to push as commit 7b06188.
Since your change was applied there have been 57 commits pushed to the master branch:

4eae9b5: 8354541: Remove Shenandoah post barrier expand loop opts
31e293b: 8354552: Open source a few Swing tests
3e3dff6: 8354451: Open source some more Swing popup menu tests
... and 54 more: https://git.openjdk.org/jdk/compare/cec48ed270d3bdf704c389a091b42a32c2ed6440...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-04-17T18:31:21Z

@stuart-marks Pushed as commit 7b06188.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

RogerRiggs · 2025-04-17T19:02:41Z

I probably would have waited to integrate until the person who requested changes had a chance to re-approve.

stuart-marks · 2025-04-17T21:32:01Z

Sorry, @AlanBateman and @naotoj and I have been over this code a bunch of times, and I thought their reviews were sufficient.

8354464: Additional cleanup setting up native.encoding

c71616c

openjdk bot added the core-libs [email protected] label Apr 12, 2025

Rename variables to make clear they're not used.

328fdd2

stuart-marks marked this pull request as ready for review April 14, 2025 22:23

openjdk bot added the rfr Pull request is ready for review label Apr 14, 2025

naotoj reviewed Apr 15, 2025

View reviewed changes

stuart-marks added 2 commits April 15, 2025 19:57

Merge branch 'master' into JDK-8354464-additional-cleanup-native-enco…

7a42a2d

…ding

Move asserts into platform-independent code.

37cd3ed

AlanBateman approved these changes Apr 16, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Apr 16, 2025

RogerRiggs suggested changes Apr 16, 2025

View reviewed changes

Remove encoding parameter from SetupI18nProps.

d1ba250

openjdk bot removed the ready Pull request is ready to be integrated label Apr 17, 2025

naotoj approved these changes Apr 17, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Apr 17, 2025

openjdk bot added the integrated Pull request has been integrated label Apr 17, 2025

openjdk bot closed this Apr 17, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Apr 17, 2025

8354464: Additional cleanup setting up native.encoding #24607

8354464: Additional cleanup setting up native.encoding #24607

Uh oh!

Conversation

stuart-marks commented Apr 12, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Apr 12, 2025

Uh oh!

openjdk bot commented Apr 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Apr 12, 2025

Uh oh!

mlbridge bot commented Apr 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

naotoj left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlanBateman left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

naotoj left a comment

Choose a reason for hiding this comment

Uh oh!

stuart-marks commented Apr 17, 2025

Uh oh!

openjdk bot commented Apr 17, 2025

Uh oh!

openjdk bot commented Apr 17, 2025

Uh oh!

RogerRiggs commented Apr 17, 2025

Uh oh!

stuart-marks commented Apr 17, 2025

Uh oh!

Uh oh!

stuart-marks commented Apr 12, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Apr 12, 2025 •

edited

Loading

mlbridge bot commented Apr 14, 2025 •

edited

Loading